Live Game Lobby

ABSTRACT

A three-dimensional rendering of a game space for a first instance of a game is displayed. The first instance of the game requests position information of avatars in game spaces of other instances of the game. Position information and a player identification for an avatar in another instance of the game is received. A position object is generated based on the position information and player identification, the position object being unable to interact with other objects in the first instance of the game. A graphical representation of the position object is displayed in the three-dimensional rendering of the game space of the first instance of the game, the graphical representation of the position object being positioned in the three-dimensional rendering of the game space based on the received position information.

BACKGROUND

Many available video games provide two formats of game play: solo gameplay, and multi-player game play. In solo game play, a single playerplays within a single instance of a game world on a single gamingmachine such as a gaming console or a personal computer. In multi-playergaming, the gaming machine is networked with other gaming machines toallow multiple players to play within the same instance of the gamingworld so that each of the players can interact with the same objects inthe gaming world and so that the gaming world appears the same to eachplayer.

There are several different types of multi-player gaming available. Inmassive multi-player online games, thousands of players share the sameinstance of a game world that is being played on a server. New playersare added to the instance of the game world by logging into the server.This creates open access to the instance of the game world and allowsplayers to interact with every player logged into the server.

In massive open online play, players log into a server in the samemanner as they would in a massive multi-player online game. However,instead of placing all players in the same instance of the game, theserver creates multiple parallel instances of the game. For eachinstance, the server automatically identifies a small group of playersthat are to be assigned to that instance. For example, the server mayidentify eight players that are playing within a single instance. Inmost cases, the groups are formed based on the position of the players'avatars in the game world. An avatar is the representation of the playerin the game and can take the form of a character or an object, such as acar. If an avatar moves too far away from the other avatars in the gameworld, the server will transfer the avatar to another group, and thus toanother instance of the game. This transfer happens automaticallywithout any input from the players.

In a third type of multi-player game, a player acts as a host and sendsinvitations to other players to join in an instance of the game. To sendsuch invitations, the player typically interrupts a game they arecurrently playing to access a list of friends or available players andto initiate a command that sends the invitation to each of the players.

The discussion above is merely provided for general backgroundinformation and is not intended to be used as an aid in determining thescope of the claimed subject matter.

SUMMARY

A three-dimensional rendering of a game space for a first instance of agame is displayed. The first instance of the game requests positioninformation of avatars in game spaces of other instances of the game.Position information and a player identification for an avatar inanother instance of the game is received. A position object is generatedbased on the position information and player identification, theposition object being unable to interact with other objects in the firstinstance of the game. A graphical representation of the position objectis displayed in the three-dimensional rendering of the game space of thefirst instance of the game, the graphical representation of the positionobject being positioned in the three-dimensional rendering of the gamespace based on the received position information.

This Summary is provided to introduce a selection of concepts in asimplified form that are further described below in the DetailedDescription. This Summary is not intended to identify key features oressential features of the claimed subject matter, nor is it intended tobe used as an aid in determining the scope of the claimed subjectmatter. The claimed subject matter is not limited to implementationsthat solve any or all disadvantages noted in the background.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a perspective view of a gaming console.

FIG. 2 is a block diagram of components of a gaming console.

FIG. 3 is a block diagram of network connections between servers andgaming machines.

FIG. 4 is a flow diagram for providing positional objects in separateinstances of games.

FIG. 5 is a flow diagram of a method of initiating a multi-player game.

FIG. 6 is a screen shot showing a displayed positional object.

FIG. 7 is a screen shot showing a highlighted positional object.

FIG. 8 is a screen shot showing an invite menu.

FIG. 9 is a screen shot showing an avatar brought into an instance of agame.

FIG. 10 is a screen shot of an avatar displayed within a displayedstructure of an instance of a game.

FIG. 11 is a screen shot of the positional object of FIG. 10highlighted.

FIG. 12 is a screen shot of an invitation.

FIG. 13 is a screen shot after a player has been moved to anotherinstance of a game.

FIG. 14 is a block diagram of network connections during a multi-playergame.

DETAILED DESCRIPTION

FIG. 1 shows an exemplary gaming and media system 100. The followingdiscussion of this Figure is intended to provide a brief, generaldescription of a suitable environment in which certain methods may beimplemented.

As shown in FIG. 1, gaming and media system 100 includes a game andmedia console (hereinafter “console”) 102. Console 102 is configured toaccommodate one or more wireless controllers, as represented bycontrollers 104(1) and 104(2). A command button 135 on console 102 isused create a new wireless connection between on of the controllers andthe console 102. Console 102 is equipped with an internal hard diskdrive (not shown) and a media drive 106 that supports various forms ofportable storage media, as represented by optical storage disc 108.Examples of suitable portable storage media include DVD, CD-ROM, gamediscs, and so forth. Console 102 also includes two memory unit cardreceptacles 125(1) and 125(2), for receiving removable flash-type memoryunits 140.

Console 102 also includes an optical port 130 for communicatingwirelessly with one or more devices and two USB (Universal Serial Bus)ports 110(1) and 110(2) to support a wired connection for additionalcontrollers, or other peripherals. In some implementations, the numberand arrangement of additional ports may be modified. A power button 112and an eject button 114 are also positioned on the front face of gameconsole 102. Power button 112 is selected to apply power to the gameconsole, and can also provide access to other features and controls, andeject button 114 alternately opens and closes the tray of a portablemedia drive 106 to enable insertion and extraction of a storage disc108.

Console 102 connects to a television or other display (not shown) viaA/V interfacing cables 120. In one implementation, console 102 isequipped with a dedicated A/V port (not shown) configured forcontent-secured digital communication using A/V cables 120 (e.g., A/Vcables suitable for coupling to a High Definition Multimedia Interface“HDMI” port on a high definition monitor 150 or other display device). Apower cable 122 provides power to the game console. Console 102 may befurther configured with broadband capabilities, as represented by acable or modem connector 124 to facilitate access to a network, such asthe Internet.

Each controller 104 is coupled to console 102 via a wired or wirelessinterface. In the illustrated implementation, the controllers areUSB-compatible and are coupled to console 102 via a wireless or USB port110. Console 102 may be equipped with any of a wide variety of userinteraction mechanisms. In an example illustrated in FIG. 1, eachcontroller 104 is equipped with two thumbsticks 132(1) and 132(2), aD-pad 134, buttons 136, User Guide button 137 and two triggers 138. Bypressing and holding User Guide button 137, a user is able to power-upor power-down console 102. By pressing and releasing User Guide button137, a user is able to cause a User Guide Heads Up Display (HUD) userinterface to appear over the current graphics displayed on monitor 150.The controllers described above are merely representative, and otherknown gaming controllers may be substituted for, or added to, thoseshown in FIG. 1.

Controllers 104 each provide a socket for a plug of a headset 160. Audiodata is sent through the controller to a speaker 162 in headset 160 toallow sound to be played for a specific player wearing headset 160.Headset 162 also includes a microphone 164 that detects speech from theplayer and conveys an electrical signal to the controller representativeof the speech. Controller 104 then transmits a digital signalrepresentative of the speech to console 102. Audio signals may also beprovided to a speaker in monitor 150 or to separate speakers connectedto console 102.

In one implementation (not shown), a memory unit (MU) 140 may also beinserted into one of controllers 104(1) and 104(2) to provide additionaland portable storage. Portable MUs enable users to store game parametersand entire games for use when playing on other consoles. In thisimplementation, each console is configured to accommodate two MUs 140,although more or less than two MUs may also be employed.

Gaming and media system 100 is generally configured for playing gamesstored on a memory medium, as well as for downloading and playing games,and reproducing pre-recorded music and videos, from both electronic andhard media sources. With the different storage offerings, titles can beplayed from the hard disk drive, from optical disk media (e.g., 108),from an online source, from a peripheral storage device connected to USBconnections 110 or from MU 140.

FIG. 2 is a functional block diagram of gaming and media system 100 andshows functional components of gaming and media system 100 in moredetail. Console 102 has a central processing unit (CPU) 200, and amemory controller 202 that facilitates processor access to various typesof memory, including a flash Read Only Memory (ROM) 204, a Random AccessMemory (RAM) 206, a hard disk drive 208, and media drive 106. In oneimplementation, CPU 200 includes a level 1 cache 210, and a level 2cache 212 to temporarily store data and hence reduce the number ofmemory access cycles made to the hard drive, thereby improvingprocessing speed and throughput.

CPU 200, memory controller 202, and various memory devices areinterconnected via one or more buses (not shown). The details of the busthat is used in this implementation are not particularly relevant tounderstanding the subject matter of interest being discussed herein.However, it will be understood that such a bus might include one or moreof serial and parallel buses, a memory bus, a peripheral bus, and aprocessor or local bus, using any of a variety of bus architectures. Byway of example, such architectures can include an Industry StandardArchitecture (ISA) bus, a Micro Channel Architecture (MCA) bus, anEnhanced ISA (EISA) bus, a Video Electronics Standards Association(VESA) local bus, and a Peripheral Component Interconnects (PCI) busalso known as a Mezzanine bus.

In one implementation, CPU 200, memory controller 202, ROM 204, and RAM206 are integrated onto a common module 214. In this implementation, ROM204 is configured as a flash ROM that is connected to memory controller202 via a Peripheral Component Interconnect (PCI) bus and a ROM bus(neither of which are shown). RAM 206 is configured as multiple DoubleData Rate Synchronous Dynamic RAM (DDR SDRAM) modules that areindependently controlled by memory controller 202 via separate buses(not shown). Hard disk drive 208 and media drive 106 are shown connectedto the memory controller via the PCI bus and an AT Attachment (ATA) bus216. However, in other implementations, dedicated data bus structures ofdifferent types can also be applied in the alternative.

In some embodiments, ROM 204 contains an operating system kernel thatcontrols the basic operations of the console and that exposes acollection of Application Programming Interfaces that can be called bygames and other applications to perform certain functions and to obtaincertain data.

A three-dimensional graphics processing unit 220 and a video encoder 222form a video processing pipeline for high speed and high resolution(e.g., High Definition) graphics processing. Data are carried fromgraphics processing unit 220 to video encoder 222 via a digital videobus (not shown). An audio processing unit 224 and an audio codec(coder/decoder) 226 form a corresponding audio processing pipeline formulti-channel audio processing of various digital audio formats. Audiodata are carried between audio processing unit 224 and audio codec 226via a communication link (not shown). The video and audio processingpipelines output data to an A/V (audio/video) port 228 for transmissionto a television or other display containing one or more speakers. Someaudio data formed by audio processing unit 224 and audio codec 226 isalso directed to one or more headsets through controllers 104. In theillustrated implementation, video and audio processing components220-228 are mounted on module 214.

FIG. 2 shows module 214 including a USB host controller 230 and anetwork interface 232. USB host controller 230 is shown in communicationwith CPU 200 and memory controller 202 via a bus (e.g., PCI bus) andserves as host for peripheral controllers 104(1)-104(4). Networkinterface 232 provides access to a network (e.g., Internet, homenetwork, etc.) and may be any of a wide variety of various wire orwireless interface components including an Ethernet card, a modem, aBluetooth module, a cable modem, and the like.

In the implementation depicted in FIG. 2, console 102 includes acontroller support subassembly 240, for supporting up to fourcontrollers 104(1)-104(4). The controller support subassembly 240includes any hardware and software components needed to support wiredand wireless operation with an external control device, such as forexample, a media and game controller. A front panel I/O subassembly 242supports the multiple functionalities of power button 112, the ejectbutton 114, as well as any LEDs (light emitting diodes) or otherindicators exposed on the outer surface of console 102. Subassemblies240 and 242 are in communication with module 214 via one or more cableassemblies 244. In other implementations, console 102 can includeadditional controller subassemblies. The illustrated implementation alsoshows an optical I/O interface 235 that is configured to send andreceive signals that can be communicated to module 214.

MUs 140(1) and 140(2) are illustrated as being connectable to MU ports“A” 130(1) and “B” 130(2) respectively. Additional MUs (e.g., MUs140(3)-140(4)) are illustrated as being connectable to controller104(1), i.e., two MUs for each controller. Each MU 140 offers additionalstorage on which games, game parameters, and other data may be stored.In some implementations, the other data can include any of a digitalgame component, an executable gaming application, an instruction set forexpanding a gaming application, and a media file. When inserted intoconsole 102 or a controller, MU 140 can be accessed by memory controller202.

Headset 160 is shown connected to controller 104(3). Each controller 104may be connected to a separate headset 160.

A system power supply module 250 provides power to the components ofgaming system 100. A fan 252 cools the circuitry within console 102.

Under some embodiments, an application 260 comprising machineinstructions is stored on hard disk drive 208. Application 260 providesa collection of user interfaces that are associated with console 102instead of with an individual game. The user interfaces allow the userto select system settings for console 102, access media attached toconsole 102, view information about games, and utilize services providedby a server that is connected to console 102 through a networkconnection. When console 102 is powered on, various portions ofapplication 260 are loaded into RAM 206, and/or caches 210 and 212, forexecution on CPU 200. Although application 260 is shown as being storedon hard disk drive 208, in alternative embodiments, application 260 isstored in ROM 204 with the operating system kernel.

Gaming system 100 may be operated as a standalone system by simplyconnecting the system to monitor, a television 150 (FIG. 1), a videoprojector, or other display device. In this standalone mode, gamingsystem 100 enables one or more players to play games, or enjoy digitalmedia, e.g., by watching movies, or listening to music. However, withthe integration of broadband connectivity made available through networkinterface 232, gaming system 100 may further be operated as aparticipant in a larger network gaming community allowing, among otherthings, multi-player gaming.

The consoles described in FIGS. 1 and 2 are just one example of gamingmachines that can be used with various embodiments described herein.Other gaming machines such as personal computers may be used instead ofthe gaming console of FIGS. 1 and 2.

FIG. 3 provides a block diagram of multiple gaming machines 300, 302 and304 connected through a network 306 to an inter-player communicationserver 308 and a game-specific avatar-tracking server 310.

Player A 312 is playing game instance A 314 on gaming machine A 300.Game instance A 314 includes a game state A 316 that describes theposition and status of every object and avatar in a three-dimensionalgaming environment of game instance A 314. Players can include humanplayers such as player A 312 and artificial intelligence robots (AIbots) that control the movement of their avatar.

Player B 318 and player C 320 are playing respective separate gameinstances 322 and 324 on respective gaming machines 302 and 304. Gameinstance B 322 has game state B 326 and game instance C 324 has gamestate C 328. Game state A 316, game state B 326, and game state C 328are all different since game instance A 314, game instance B 322, andgame instance C 324 are separate instances of the game. Note that gameinstance A 314, game instance B 322, and game instance C 324 are all forthe same game but are different instances of that same game. As aresult, the separate instances may contain similar objects andenvironments but the status of at least one object or avatar will bedifferent in any two of the game instances. Further, the avatar for eachplayer in a particular instance cannot affect objects in other gameinstances. Thus, the avatar for player A in game instance A 314 cannotaffect objects in game instance B 322 or objects in game instance C 324.As described herein, players A, B and C are said to be remote from eachother because they are using separate gaming machines. Those skilled inthe art will recognize that although the players are said to be remotefrom each other, they may be located in the same building or room aslong as they are using a separate gaming machine.

Inter-player communication server 308 provides a set of communicationservices 340 that allow players to communicate with each other throughgaming machines 300, 302 and 304. In order to facilitate suchcommunications, inter-player communication server 308 includes userlogin services 342 that require the players to log into inter-playercommunication server 308. During login, login services 342 obtain agamer tag (a unique identifier associated with the user) and a passwordfrom the user, as well as a console ID that uniquely identifies thegaming machine that the user is using and a network path to the gamingmachine. The gamer tag and password are authenticated by comparing themto information stored in user records 344, which may be located on thesame server as user login services 312 or may be distributed on adifferent server or a collection of different servers. Onceauthenticated, user login services 342 stores the console ID and thenetwork path in user records 344 so that messages and downloadablecontent may be sent to the gaming machines.

Game instance A 314, game instance B 322, and game instance C 324 alsologin to game-specific avatar-tracking server 310 using login services350. Typically, these login services do not require a password, butsimply require the gamer tag. Once the game instance has been loggedinto game-specific avatar-tracking server, each game instance sends thecurrent position of the avatar for the player in the three-dimensionalgaming world of the game instance to avatar-tracking server 310. In someembodiments, each game instance may also send attributes of the player'savatar including level, region, indoors, outdoors, health, weapons, andawards. The player, avatar position, and attributes are stored in aplayer and avatar position database 352 on avatar-tracking server 310.As the player moves the avatar within the three-dimensional game worldof the game instance, the game instance provides position and attributeupdates to an avatar update 354 in avatar-tracking server 310. Based onthis information, avatar update 354 updates player and avatar positiondatabase 352 to reflect the new position and attributes of the avatar.

Under the several embodiments described below, the network structure ofFIG. 3 is used to distribute information about the position of avatarsso that an instance of a game knows the location of avatars in otherinstances of the game. The game instance then uses this positioninformation to create a position object that can be rendered in thethree-dimensional graphical environment of the gaming instance. Forexample, through these embodiments, player A is able to see a graphicalrepresentation of the position of player B's avatar in a positioncorresponding to the position of player B's avatar in game instance B322. The position objects shown in a game instance are not able tointeract with other objects in the game instance. Instead, each positionobject is a “ghost” object. Further, even though a player's avatar maybe represented by a position object in another game instance, the playerdoes not see the objects in that other game instance. Instead, theplayer only sees the objects in their own game instance. For example, ifplayer B's avatar is represented by a position object in game instance A314, player B would only see objects in game instance B 322 and wouldnot see the objects or game world of game instance A 314.

FIG. 4 provides a flow diagram of a method for generating graphicalrepresentations of position objects under one embodiment. In step 400,player A 312 and player B 318 login to inter-player communication server308 using user login services 342. At step 402, player A 312 begins soloplay of game instance A 314 on gaming machine A 300. Under oneembodiment, solo play takes place in a three-dimensional graphical spacethat is rendered by game instance A 314. As part of starting gameinstance A 314, game instance A 314 logs player A into game-specificavatar-tracking server 310 by providing the gamer tag of player A, theposition of player A's avatar in three-dimensional graphical space, andattributes of player A's avatar at step 404. Under some embodiments,game instance A 314 first checks a player-selected setting to determineif the player wants to log into avatar-tracking server 310. Under suchembodiments, the default setting can be that the game instance does notlog into the avatar-tracking server or that the game instance alwaysasks the player before attempting to log into the avatar-trackingserver. Under such embodiments, the player may use menus in the gameinstance to change the values of these settings.

At step 406, player B begins solo play of game instance B 322 on gamingmachine 302. Game instance B 322 logs player B 318 into game-specificavatar-tracking service 310 and provides an identifier for player B, thelocation of player B's avatar in the three-dimensional gaming world ofgame instance B 322, and attributes of player B's avatar at step 408.Thus, after step 408, player and avatar position database 352 includesplayer identification information for player A 312 and player B 318, theposition of the avatars in their respective game instances 314 and 322,and attributes of the avatars.

At step 410, game instance A 314 and game instance B 322 each request arespective list of players in respective playgroups for player A 312 andplayer B 314. The lists of players in each respective playgrouprepresents players that player A and player B may want to join in amultiplayer game.

At step 412, playgroup services 356 of game-specific avatar-trackingserver 310 determines the playgroups for player A 312 and player B 318.A playgroup for a player may be determined from such things as: playerswho are in a player's friends list; players who are using gamingmachines that are in a same geographic location, such as a state or acountry; players who are of comparable skill levels; and players whoengage in the same types of ingame activities such as fighting orexploring; attributes of the avatars; or some combination of thesethings. Information about a player's friends list, geographic location,and skill level, can be obtained from user records 344 on inter-playercommunication server 308 or under some embodiments from user records 358on game-specific avatar-tracking server 310. Note that other criteriamay be used to define a playgroup for a player. In general, thedefinition of a playgroup is such that if player B is in player A'splaygroup, player A will be in player B's playgroup. In the example ofFIG. 4, player A and player B are determined to be in the same playgroupat step 412. In addition, playgroup services 356 may keep a list ofplayers that it will not track, if desired, and as such not includecertain players in a playgroup even though they meet the otherrequirements for being part of the playgroup.

At step 416, the server sends player identification information andavatar position information for player B to game instance A 314 andsends player identification information and avatar position informationfor player A 312 to game instance B 322.

At step 418, game instance A 314 creates a position object, alsoreferred to as a virtual avatar, for player B's avatar and game instanceB 322 creates a position object, virtual avatar, for player A's avatar.The position objects are unable to interact with other objects in theirrespective game instances. Thus, the position object for player B'savatar in game instance A 314, has no affect on other objects in gameinstance A 314 as defined by game state A 316. In addition, the creationof a position object in a game instance does not provide access to thegame instance for another player. For example, the creation of aposition object for player B's avatar in game instance A 314 does notprovide player B 318 with access to game instance A 314. As such, playerB cannot see the objects defined by game state A 316 in game instance A314. Instead, player B can only see the objects defined in game instanceB 322 by game state B 326.

At step 420, the game instances create graphical representations of theposition objects in their respective three-dimensional graphical gameworld if the position objects are located within the current view of thecamera. For example, game instance A 314 would create a graphicalrepresentation of the position object for player B's avatar. Thegraphical representation is placed in the three-dimensional graphicalspace at a location specified by the position of the avatar in therespective other game instance. Thus, the graphical representation ofthe position object for player B's avatar in game instance A 314 wouldbe at a position that corresponds to the position of player B's avatarin game instance B 322.

FIG. 6 provides an example of a screen shot in which a graphicalrepresentation 600 of a position object is shown in a three-dimensionalgraphical environment 602. The graphical representation of positionobject 600 includes a player identifier 604 and an icon 606. In FIG. 6,the graphical representation of the position object takes the form of atwo-dimensional icon. In other embodiments, the graphical representationof the position object can include a 3D mesh that looks like the avatarof the other player, a floating two-dimensional sprite that is a pictureof the other player that is different from the avatar of the otherplayer, a symbolic geometric shape with a color or size that representsthe other player's in-game prowess, or any other desired graphicalrepresentation. In other embodiments, the player identifier 604 may notbe present in the graphical representation, but may be accessed byselecting the graphical representation of the position object.

FIG. 10 provides another example of a graphical representation 1000 of aposition object being displayed in a three-dimensional graphicalenvironment 1002. As shown in FIG. 10, since position object 1000 cannotinteract with objects in the game instance in which it is displayed, thegraphical representation 1000 of the position object can appearintersected by stationary objects such as house object 1004 in FIG. 10.In other words, position object 1000 and house object 1004 at leastpartially occupy the same space in the three-dimensional graphicalenvironment. This would generally not be possible if position object1000 were treated like other objects in the game instance.

By displaying such position objects, embodiments described herein allowa player of a current instance of a game to see where other players areplaying in their own instance of the game without those other playersaffecting the current instance of the game. Thus, the graphicalrepresentation of the position object acts as a notification to thecurrent player that other players within their playgroup are playinganother instance of the same game and their avatars are located close tothe current player's avatar. As discussed further below, this allows theplayers to initiate communications with each other to begin amultiplayer game session.

FIG. 5 provides a flow diagram of a method of using a position object toinitiate a multiplayer gaming session. In the discussion of FIG. 5,reference is made to player A and player B for illustration purposes.

In step 500 of FIG. 5, player A selects a position object for the avatarof player B to activate an invite menu. Under one embodiment, as shownin FIGS. 7 and 9, a player selects a position object by moving towardthe position object so that the position object becomes highlighted. Forinstance, in FIG. 7, position object 600 of FIG. 6 has becomehighlighted and in FIG. 11, position object 1000 of FIG. 10 has becomehighlighted as indicated by highlighting circles 700 and 1100respectively. Once the object is highlighted, the user can press abutton on the controller to activate the invite menu, which is displayedon the screen as shown in FIGS. 8 and 12. In FIG. 8, the invite menuincludes two selectable commands. The first command 800 allows the userto invite the remote player to join the user in their current game.Selectable command 802 allows the user to ask the remote player if theuser may join the remote player in their remote game. Similar commands1200 and 1202 are provided in the menu of FIG. 12.

At step 502, player A selects the command to invite the player B to jointhe player A's game state. In FIG. 8, this would involve selectingcommand 800 and in FIG. 12, this would involve selecting command 1200.At step 504, the player B accepts the invitation and the acceptance isreceived by game instance A 314. At step 506, the game state for playerB is saved by player B's game instance.

At step 508, player A's gaming machine 300 and player B's gaming machine302 begin peer-to-peer communications. Under one embodiment, this isdone using inter-player communication server 308 to obtain the networkpathway between gaming machine A 300 and gaming machine B 302. Gamingmachine A 300 and gaming machine B 302 then negotiate a communicationchannel to allow peer-to-peer communications between the two machines.

At step 510, game state A is sent to game instance B 322 and at step512, the properties of player B's avatar in game state B are added togame state A in both game instance A and game instance B. The propertiesof player B's avatar include the position of the avatar, the appearanceof the avatar and the status of the avatar, which includes informationsuch as the health or condition of the avatar, objects held by theavatar, and the experience level of the avatar in game state B of gameinstance B. Before adding the properties of player B's avatar, theposition object for player B's avatar is removed from game instance A sothat in essence player B's avatar replaces the position object forplayer B's avatar. After steps 510 and 512, game instance A and gameinstance B have been synchronized to game state A and player B's avatarhas been added to game state A in place of the position object forplayer B's avatar.

During the replacement of the position object with player B's avatar, aconflict check will be made to ensure that player B's avatar can beplaced in the same position in game state A without interfering with anexisting object in game state A. If there is a position conflict, theposition of player B's avatar will be shifted to avoid any existingobjects in game state A and to place player B's avatar in a “safe”position, such that player B's avatar will not be immediately destroyedbased on its positioning.

At step 516, game instance A removes the position object for player B'savatar from the three-dimensional graphical environment and insteaddisplays player B's avatar. An example of the removal of a positionobject and the insertion of an avatar in its place is shown in FIG. 9where position object 600 of FIG. 6 has been removed and avatar 900 hasbeen inserted in its place.

At step 518, game instance B displays a graphical representation of thegame space defined by game state A. Thus, after steps 516 and 518,player A can see the avatar of player B, and player B can see the gamespace of player A's game state. In addition, player B is able tointeract with the objects in player A's game state. Thus, player B hadits avatar added to player A's game. Changes made by player B's avatarto objects in player A's game will now be reflected in game state A.

After player B's avatar has been added to game state A and game state Ahas been provided to game instance B, an indication may be sent togame-specific avatar-tracking server 310 that these events haveoccurred. Under one embodiment, based on these events, game-specificavatar-tracking server 310 discontinues tracking the avatars for gameinstance A and game instance B to thereby limit the number of playersthat may be added to game state A. In other embodiments, game-specificavatar-tracking server 310 allows more than two players to play in thesame game state and will continue tracking the position of avatars in agame state until a maximum number of avatars in a particular game stateis reached. When the maximum number of avatars is reached, the playersand their avatars are removed from player and avatar position database352 and game-specific avatar-tracking server 310.

FIG. 14 shows an example of the state of the network connections afterstep 520. As indicted in FIG. 14, the connections between game instance314 and server 310 and game instance 320 and server 310 have been brokenand a new connection between game instance 314 and game instance 322 hasbeen created. Note that game instance 324 continues to be connected togame-specific avatar-tracking server 310.

Returning to FIG. 5, player A may alternatively select the command torequest insertion into game state B as shown by step 522. If player Bgrants this request at step 524, an indication that player B has grantedthe request is received by game instance 314 and game state A is savedat step 526 by game instance 314. Player A's gaming machine and playerB's gaming machine then begin peer-to-peer communications at step 528 inthe same manner as discussed above for step 508.

At step 530, game state B is sent to game instance A and is loaded intogame instance A. At step 532 the properties of player A's avatar areadded to game state B in place of the position object for player A'savatar. At step 534, game instance B removes the position object forplayer A's avatar from the three-dimensional graphical environment anddisplays player A's avatar in its place.

FIG. 13 provides an example of game instance A displaying a graphicalrepresentation based on game state B in step 536. In FIG. 13, theposition of player A's avatar is the same as in FIG. 10 such that street1006, street 1008 and mailbox 1010 are shown in both views. However, inFIG. 13, house 1004 has been removed, tree 1300 has been added, positionobject 1000 has been removed and player B's avatar 1302 has been added.Tree 1300 and player B's avatar 1302 are part of game state B. However,house 1004 was part of game state A. As such, when game instance Aswitches to displaying game state B, house 1004 disappears, and tree1300 and avatar 1302 appear.

At step 540, an optional step of sending an indication that player A'savatar has been added to game state B and that game instance A has beensynchronized to game state B may be sent to game-specificavatar-tracking server 310.

Using menu commands, the player that has been added to a game instancemay quit the game instance. When a player elects to quit a gameinstance, attributes of the player's avatar that have changed, such asreaching a new level or reward, can be stored on the players gamingmachine. Alternatively, the player's avatar can be returned to the gameinstance they were playing before being added to the other player's gameinstance.

Although the subject matter has been described in language specific tostructural features and/or methodological acts, it is to be understoodthat the subject matter defined in the appended claims is notnecessarily limited to the specific features or acts described above.Rather, the specific features and acts described above are disclosed asexample forms of implementing the claims.

1. A method comprising: initiating game play in a first instance of agame for a first player; receiving position information indicating theposition of an avatar associated with a second player in a secondinstance of the game, the first instance and the second instance beingseparate such that the avatar associated with the second player cannotaffect objects in the first instance of the game; creating a virtualavatar for the second player in the first instance of the game, thevirtual avatar such that the virtual avatar cannot affect objects in thefirst instance of the game; and rendering a graphical representation ofthe virtual avatar in a three-dimensional space in the first instance ofthe game at a position that is based on the position information for theavatar associated with the second player in the second instance of thegame.
 2. The method of claim 1 further comprising: receiving anindication from the first player that the second player is to be invitedto play in the first instance of the game; receiving an indication thatthe second player has accepted the invitation; and updating game stateinformation for the first instance of the game to include the avatar forthe second player.
 3. The method of claim 2 wherein updating the gamestate information comprises updating the game state information with theproperties of the avatar for the second player in the second instance ofthe game.
 4. The method of claim 3 further comprising providing gamestate information for the first instance of the game to synchronize thegame state of the second instance of the game to the game state of thefirst instance of the game and to thereby allow the avatar for thesecond player to interact with objects in the first instance of thegame.
 5. The method of claim 1 further comprising providing positioninformation for an avatar associated with the first player in the firstinstance of the game to allow a graphical representation of the firstplayer to appear in the second instance of the game, the graphicalrepresentation such that it cannot affect objects in the second instanceof the game.
 6. The method of claim 1 wherein the graphicalrepresentation of the virtual avatar comprises a picture of the secondplayer that is different from the avatar associated with the secondplayer.
 7. The method of claim 1 further comprising: receiving anindication from the first player that they would like to join the secondinstance of the game; receiving an indication that the second playerwill allow the first player to join the second instance of the game;saving game state information for the first instance of the game; andloading game state information to reflect the game state of the secondinstance of the game with the avatar associated with the first playerpositioned in the second instance of the game.
 8. A computer-readablemedium having computer-executable instructions for performing stepscomprising: receiving position information for a first avatar in a firstinstance of a game being played on a first machine, the first avatarassociated with a first player; receiving position information for asecond avatar in a second instance of the game being played on a secondmachine, the second avatar associated with a second player, the firstinstance and the second instance being separate such that the secondavatar cannot interact with objects in the first instance; providing theposition information for the first avatar to the second machine; andreceiving an indication that the first avatar has been added to a gamestate of the second instance of the game and a game state of the firstinstance of the game has been synchronized to the game state of thesecond instance of the game.
 9. The computer-readable medium of claim 8wherein providing the position information for the first avatarcomprises determining that the first player is in a playgroup for thesecond player.
 10. The computer-readable medium of claim 9 whereindetermining that the first player is in a playgroup for the secondplayer comprises determining at least one fact from a group of factscomprising: that the first player is in the second player's friendslist; that the first machine is within a geographic threshold of thesecond machine; that the first player and the second player are ofcomparable skill levels, and that the first player and the second playerengage in the same type of in-game activities.
 11. The computer-readablemedium of claim 10 further comprising receiving attributes of the firstavatar and attributes of the second avatar.
 12. A computer-readablemedium having computer-executable instructions for performing stepscomprising: displaying a three-dimensional rendering of a game space fora first instance of a game; requesting position information of avatarsin game spaces of other instances of the game; receiving positioninformation and a player identification for an avatar in anotherinstance of the game, the player identification identifying a secondplayer; generating a position object based on the position informationand player identification, the position object being unable to interactwith other objects in the first instance of the game; and displaying agraphical representation of the position object in the three-dimensionalrendering of the game space of the first instance of the game, thegraphical representation of the position object being positioned in thethree-dimensional rendering of the game space based on the receivedposition information.
 13. The computer-readable medium of claim 12wherein rendering a graphical representation of the position objectcomprises rendering the graphical representation even though a graphicalrepresentation of another object is rendered in at least part of thesame space as the graphical representation of the position object. 14.The computer-readable medium of claim 12 further comprising allowing aplayer to select the graphical representation of the position object inthe three-dimensional rendering of the game space in the first instanceof the game.
 15. The computer-readable medium of claim 14 furthercomprising upon selection of the graphical representation of theposition object displaying a selection menu that includes a selectablecommand to send an invitation to the second player to play in a gamestate defined for the first instance of the game.
 16. Thecomputer-readable medium of claim 15 wherein displaying a selection menufurther comprises displaying a selectable command to send a request tothe second player for the player to join a game state defined for theother instance of the game.
 17. The computer-readable medium of claim 15further comprising receiving an indication that the player has selectedthe command to send an invitation to the second player to play in thegame state defined for the first instance of the game, receiving anindication that the second player has accepted the invitation, andsending game state information describing the game state defined for thefirst instance of the game to a remote device to allow the second playerto play in the game state defined for the first instance of the game.18. The computer-readable medium of claim 17 further comprisingreceiving data describing properties of the avatar in the other instanceof the game, using the data to generate the avatar in the first instanceof the game, and displaying a graphical representation of the avatar inthe three-dimensional rendering of the game space of the first instanceof the game.
 19. The computer-readable medium of claim 18 wherein thegraphical representation of the avatar is different from the graphicalrepresentation of the position object.
 20. The computer-readable mediumof claim 16 further comprising receiving an indication that the playerhas selected the command to send a request to the second player for theplayer to join the other instance of the game, receiving an indicationthat the second player has accepted the request, saving the game stateof the first instance of the game, receiving game state informationdescribing the game state of the other instance of the game, and sendingproperties of an avatar associated with the player.